This chapter contains information you might find helpful when using CUBE Analyst. Topics include:

• Approaches to running CUBE Analyst
• Selection of model form
• Information in the optimization log file
• Computation times
• Running CUBE Analyst from CUBE Voyager

Approaches to running CUBE Analyst

There are several approaches that the user may adopt towards running CUBE Analyst, which vary according to the information available to the user about the estimation of any particular matrix. The approaches may be categorized as:

• Initial estimation
• Re-Estimation with altered data: ”Warm starting”
• Constrained model parameters
• Controlling the optimization process

Initial estimation

Only basic input data is required, as contained in the routes (RCP for TRIPS, PATH or ICP for CUBE Voyager users), matrix, trip end, and screenline files (as well as optionally a network file with part-trip data). Program control parameters are allowed to take default values. Occasionally, an input model parameter file may be required to influence the model form by fixing some parameter values.

Re-Estimation with altered data: ”Warm starting”

In this case the model parameter, gradient search, and intercept files from the last (or initial) estimation run are input, additionally to the user input data.

Warm starting is only valid when the ”structure” of the estimation is unaltered, this means that the number of data items, screenline locations, and routings should not be altered. However, data values and confidence levels may be changed.

Warm starting is useful either to split an estimation into more than one run of CUBE Analyst, for the sake of convenience, or to undertake sensitivity analysis on the effects of altered data or confidence level values. When a run of CUBE Analyst is split for convenience, and no input data is changed, then it is efficient to set the parameter UMAX to the value reported by CUBE Analyst at the final iteration of the previous run.

Constrained model parameters

Model parameters may be constrained to:

• Reflect a user-specified value (for example, of a and b parameters)
• Partition an estimation into sub-problems to be accommodated within computing resources
• Alter the nature of the trip estimation equation

If model parameters are fixed or freed from run to run then the gradient search file from one run should not be used in the next.

Note that CUBE Analyst may itself constrain model parameters. This occurs when the estimated Hessian matrix is found to be, mathematically speaking, ”non-positive definite,” which arises when one or more model parameters are ”degenerate.” That is, a model parameter is not contributing independently of another model parameter.

In these circumstances, CUBE Analyst gives a message reporting how many such model parameters it is constraining, which is of the form:

ME (I): XXX MODEL PARAMETERS ARE NOT CONTRIBUTING TO THE ESTIMATION

The constrained model parameters are listed in CUBE Analyst’s log file.

It is not necessarily a cause for concern when CUBE Analyst constrains model parameters in this way, although it is a signal that not all data is of value to the estimation because it is strongly correlated with other data. For instance, link flow counts on adjacent links of a main road may refer to substantially the same trips and hence one count is (mathematically) redundant. It is thus most frequently the case that Xx model parameters are constrained by CUBE Analyst, although other model parameters may be constrained too.

Controlling the optimization process

Normally program control parameters should be allowed to take their default values. However, computation times may be improved by judicious setting of the control parameters. This is discussed further in Computation times and in Tuning estimation performance.

Selection of model form

CUBE Analyst provides capability for the user to control the structure of the solution and how it is achieved. This section describes these possibilities. However, it may be observed that CUBE Analyst is usually run with the full, default model form. It may be shown that in this form, the X_K parameter is, strictly redundant, although it is of value in providing extra degrees of freedom by which CUBE Analyst can handle the effects of errors and inconsistencies in the input data.

The number of possible parameters in a model is:

• Two for each zone (that is the a(i) and b(j))
• One for each screenline (the X(k))
• Two more if any cost data is to be used ( and )

The model parameter file contains a value for the parameter, the upper and lower bounds for the parameter, and a scaling factor. The scaling factor is used only to assist the optimization process in ensuring that maximum accuracy is obtained. It should be set equal to the expected value of the parameter in the final solution—it is only necessary to make this scaling factor of the same order of magnitude if there are difficulties in ensuring convergence. If no such difficulties are apparent then the scaling factor can just be set to 1.0.

The lower and upper bounds for the parameters allow the user to specify the degrees of freedom which are permitted. In particular if a model parameter is set to 1.0 and its lower and upper bounds are also set to this value then a number of standard forms for the matrix estimation process can be achieved. For example:

• Setting all a(i), b(j) and X(k) equal to a fixed value (for example, 1.0) together with their bounds then the problem is reduced to a Gravity model driven only by the cost data (that is, only and are allowed to vary). (Note that varying values of a(i) and b(j) can be used to scale the numbers of trips per zone).
• Setting and and their bounds to a particular value allows the estimation process to use cost data which has been previously calibrated.
• Setting a(i), b(j) and and to a fixed value and allowing x(k) to be free provides a ”link constraint model.”
• Setting x(k), and to fixed value gives a growth factor model.
• Setting and to a fixed value allows a growth factor link model (note that and b are only defined if cost data is supplied) .
• Setting a(i) and b(j) to a fixed value defines a link gravity model.

In some of these cases input data although defined and requested by the program is not used by the estimation process. The data that is used in these special cases is summarized in the following table.

Data used in different reduced model forms

It should be observed that there are no specific model parameters associated with part-trip data, so this form of data is not relevant to discussions of model forms.

Information in the optimization log file

The levels of report, determined by the setting of the IREP parameter are as follows:

• IREP=1 A report is only produced at the end of the run. This shows:
  • The reason that the optimization has been halted
  • The value of the objective function (the maximum likelihood)
  • The current step size
  • The minimum tolerance step size

In addition a number of important variables defining the size of the problem and the parameters input to CUBE Analyst are also displayed.

• IREP=2 A report is produced as for IREP 1 and also a report at each iteration. This shows:
  • The iteration number and whether or not progress was made at this iteration.
  • The number of evaluations made so far in this run. This is the number of times that a matrix and associated trip and screenline data have been calculated together with the likelihood function.
  • The current step size.
  • The step size tolerance.
• IREP=3 A report is produced as for IREP 2 and also a report at each time the model is evaluated to calculate the effects of a particular choice of model parameter. This shows:
  • The evaluation number
  • The step size multiplier (used if no progress is made in the first evaluation to reduce the step size, ALPHA)
  • The step size (STEP)
  • The objective function at the last iteration and at the point at which the function evaluation is made. (FTRIAL and FBEST)
  • A measure of the gradient at the last iteration at the point at which the function evaluation is made
  • Other internal variables used only for intermediate calculations (FGOLD, FJJS)

In addition, reports may be output to the execution log file if the gradient search matrix is found to be unstable and has to be re-initialized.

Computation times

Program control parameters should usually take their default values. However, computation times may be improved by setting the set of parameters shown in the following table.

Parameters for influencing computation times

Running CUBE Analyst from CUBE Voyager

You can run CUBE Analyst from CUBE Voyager. This section discusses:

Running CUBE Analyst from a VOYAGER script

Files

Running CUBE Analyst from a VOYAGER script

CUBE Analyst can be executed via a RUN PGM statement, where the program name needs to be specified as ”MVESTM71.”

CUBE Analyst needs to be told the name of the control file to use, and how much memory it can take. The former is achieved via the CTLFILE keyword. The memory setting is achieved by specifying a PARAMETERS entry on the RUN PGM command of the form PARAMETERS="/m=14" where the number ”14” indicates the amount of memory to use in MB. If no PARAMETERS entry is specified, a default amount will be applied which will insufficient for larger problems.

For example, the following command:

RUN PGM="MVESTM71", CTLFILE="C:\Test\Me_Test.ctl", PARAMETERS="/m=100"
ENDRUN

will run CUBE Analyst, providing 100 MB of memory.

Files

For CUBE Voyager users, the intercept file can be generated by HIGHWAY and PT. In this case the intercept file name should always be defined, along with the option INTCPT=T. Alternatively, HIGHWAY can be used to generate a CUBE Voyager Path file, which is input to CUBE Analyst, which will create the screenline Intercepts from the paths.